1. Technical Field
The present invention relates to a method of adapting client communications traffic for encapsulation within carrier Ethernet by providing an appropriate client/server adaptation mapping protocol for the traffic in a communications network and related aspects thereof.
In particular but not exclusively, the invention relates to a mapping protocol for a plurality of different types of client traffic into Ethernet traffic for transport over an Ethernet carrier network which removes the need for individual Ethertypes to identify the different types of client traffic.
2. Related Art
Ethernet was originally devised as a connectionless packet (Ethernet frame) based communications protocol for local area networks. More recently, however, Ethernet standards are emerging that have extended the reach of the communications protocol to wider area networks such as the Provider Backbone Bridging (PBB) being developed in the International Electrical and Electronic Engineering (IEEE) standards body as 802.1ah. This allows the transparent carriage of a client Ethernet layer network over a server Ethernet layer network. However, since the server Ethernet layer network is connectionless it cannot provide any strong resource assurances to the client Ethernet layer network.
To address this Provider Backbone Bridging-Traffic Engineered (PBB-TE) is also being developed by the IEEE as the 802.1Qay standard. The proposed 802.1Qay standard describes how an Ethernet hierarchy can be implemented to transparently carry conventional (connectionless) Ethernet client LANs over a connection-oriented packet-switched transport network infrastructure as a carrier service. However, where a PBB-TE carrier network is provided problems exist when other non-Ethernet traffic is to be transported over the PBB-TE network. This is not possible using the existing 802.1ah frame structure which is predicated on an Ethernet client.
PBB-TE is a connection-oriented Ethernet protocol which enables connectionless Ethernet to be carried as a client signal in the connection-oriented Ethernet layer using MAC in MAC encapsulation (MAC signifies here Media Access Control). Non-Ethernet client signals do not use MAC in MAC encapsulation. Moreover, it is desirable for non-Ethernet clients to be carried directly over a PBB-TE network using 802.1ad specified Ethernet equipment. This requires the client protocol to be identified using an Ethertype which acts as the protocol identifier. However, this is a far from ideal solution as many non-Ethernet clients do not have an Ethertype currently specified (and may never get such Ethertypes).
Whatever form of Ethernet to be used as a carrier technology, either in its connectionless or connection-oriented form, client traffic must be identified. The connection-oriented packet-switched and connectionless Ethernet standards require client traffic, by which term is meant a communications signal corresponding to another communications protocol which is encapsulated within the payload of the Ethernet frame, to be identified by means of a predetermined field value in the frame header referred to by those of ordinary skill in the art as an “Ethertype”. Each different type of communications protocol requires an Ethertype identifier before it can be transported using Ethernet. To obtain an Ethertype, an application is submitted to the Ethernet standards body which is a time-consuming process.
Accordingly, a problem exists in that client traffic cannot be encapsulated within carrier Ethernet unless an Ethertype already exists for that client traffic type. A possible solution would be to request new Ethertypes for all the possible types of client traffic (in addition to Ethernet) that one may wish to carry in advance. Another possible solution is to map the client Ethernet frames into other technologies instead of using an Ethernet-based server layer network. For example, in SDH/SONET and OTN the standardised mechanism is to use Generic Framing Procedure (GFP) and on a PON a similar mechanism known as GPON Encapsulation Mode (GEM). This does not, of course, resolve the problem of how to carry such clients over an Ethernet-based server layer network.